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Honorable Commissioner: 

This is an Appeal Brief filed pursuant to 37 CFR § 41.37 in response to the Final Office Action 
of March 21, 2006, and pursuant to the Notice of Appeal filed May 25, 2006. 



The real party in interest in accordance with 37 CFR § 41.37(c)(l)(i) is the patent assignee, 
International Business Machines Corporation ("IBM"), a New York corporation having a place 
of business at Armonk, New York 10504. 

RELATED APPEALS AND INTERFERENCES 

There are no related appeals or interferences within the meaning of 37 CFR § 41 .37(c)(l)(ii). 



REAL PARTY IN INTEREST 



AUS920010853US1 
APPEAL BRIEF 

STATUS OF CLAIMS 

Status of claims in accordance with 37 CFR § 41.37(c)(l )(iii): Twenty-one claims are filed in 
the original application in this case. Claims 1-21 are rejected in the Final Office Action. Claims 
1-21 are on appeal. 

STATUS OF AMENDMENTS 

Status of amendments in accordance with 37 CFR § 41.37(c)(l)(iv): No amendments were 
submitted after final rejection. The claims as currently presented are included in the Appendix of 
Claims that accompanies this Appeal Brief 

SUMMARY OF CLAIMED SUBJECT MATTER 

Applicants provide the following concise summary of the claimed subject matter according to 37 
CFR § 41 .37(c)(l)(v), including references to the specification by page and line number and to 
the drawings by reference characters. There are three independent claims in the present case, 
claims 1, 8, and 15. Claim 1 is a method claim. Claims 8 and 15 claim respectively system and 
computer program product aspects of the method of claim 1 . 

Claim 1 of the present application claims: 

1 . A method of email administration comprising the steps of: 

receiving in a transcoding gateway from a client device one or more email 
display status attributes describing one or more email display capability statuses 
for a domain; 
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receiving in the transcoding gateway from a sender an email display capability 
status request for the domain, wherein the capability status request comprises a 
domain identification; 

finding, in dependence upon the domain identification, at least one email display 

capability status record for the domain, wherein the email display capability status 
record for the domain comprises at least one of the email display capability status 
attributes; and 

sending at least one of the email display capability status attributes to the sender. 

The means plus function claim elements permitted by 35 U.S.C. § 1 12, sixth paragraph, for 
independent claim 8 is identified as follows. Note the precise correspondence with the elements 
of claims 1 and 15: 

8. A system of email administration comprising: 

means for receiving in a transcoding gateway from a client device one or more 
email display status attributes describing one or more email display capability 
statuses for a domain; 

means for receiving in the transcoding gateway from a sender an email display 
capability status request for the domain, wherein the capability status request 
comprises a domain identification; 

means for finding, in dependence upon the domain identification, at least one 
email display capability status record for the domain, wherein the email display 
capability status record for the domain comprises at least one of the email display 
capability status attributes; and 
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means for sending at least one of the email display capability status attributes to 
the sender. 

The means plus function claim elements permitted by 35 U.S.C. § 1 12, sixth paragraph, for 
independent claim 15 are identified as follows. Note the precise correspondence with the 
elements of claims 1 and 8: 

15. A computer program product of email administration comprising: 

a recording medium; 

means, recorded on the recording medium, for receiving in a transcoding 
gateway from a client device one or more email display status attributes 
describing one or more email display capability statuses for a domain; 

means, recorded on the recording medium, for receiving in the transcoding 
gateway from a sender an email display capability status request for the domain, 
wherein the capability status request comprises a domain identification; 

means, recorded on the recording medium, for finding, in dependence upon the 
domain identification, at least one email display capability status record for the 
domain, wherein the email display capability status record for the domain 
comprises at least one of the email display capability status attributes; and 

means, recorded on the recording medium, for sending at least one of the email 
display capability status attributes to the sender. 

The portion of the original specification that is most pertinent to claim 1 of the present 
application is pages 43-47 and Figure 17. The subject matter of claim 1 is concisely summarized 
as follows with a description begirming at line 1 of page 43 in the original application and with 
reference numbers in parenthesis referencing Figure 17: 
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Turning now to Figure 1 7, an additional exemplary embodiment is shown as a 
method of email administration that includes receiving (1705) through a 
transcoding gateway (100), from a client device (1726), one or more email display 
status attributes describing one or more email display capability statuses for a 
domain. The email display status attributes typically are gathered into display 
capability status records (1730) of a kind illustrated in more detail in Figure 1 9. 



Embodiments of the kind shown in Figure 1 7 typically include receiving (1704) in 
a transcoding gateway (100) from a sender (1402) an email display capability 
status request (1706) for a domain, in which the capability status request includes 
a domain identification (1409). As mentioned earlier in this specification, 
"domain" refers to a group of client devices administered together and identified 
by a common network address, typically an internet protocol address, that 
resolves to a domain name. Figure 19 illustrates a number of exemplary display 
capability status records (1730) for client devices in the domain 'grandma.net.' 
Although, the example capability status records in Figure 19 are for one domain 
only, in fact, a transcoding gateway in many embodiments serves more than one 
domain. The domain identification (1409 on Figure 17) in various embodiments 
is implemented, for example, as an internet address, internet protocol address, or 
as a domain name. In this specification, exemplary domain identifications, for 
convenience of reference, are generally taken as domain names. 

The example embodiment of Figure 17 includes finding (1714), in dependence 
upon the domain identification (1409), at least one email display capability status 
record (1730) for the domain, wherein the email display capability status record 
for the domain includes display capability status attributes describing a status of 
an email display capability for the domain. Embodiments typically include 
sending (1720) at least one of the email display capability status attributes (1718) 
to the sender. This illustrates embodiments making direct use of domain names 
(1415) without using a sender identification to find capability records. Such 
embodiments typically return for sending (1720) back to the sender display 
capability status attributes for all the display capabilities for a domain. For a 
capability request for the domain 'grandma.net,' as shown in Figure 1 7, such an 
embodiment returns attributes for the ten display capabiHty status records (1950) 
through (1968). Although it is perfectly useful in the case of grandma's house to 
send all the capability status records, in many embodiments, it is more useful to 
have additional limits on the number or capability records returned to the sender, 
especially in domains having many client devices having many display 
capabilities. Business, education, public, and Internet domains, for example, 
often have very large numbers of display devices and display capabilities. 

Because claims 8 and 15 contain elements parallel to claim 1, the concise summary above of 
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claim 1 is applicable also to claims 8 and 15. The acts described in this concise summary above 
of the method of claim 1 are also the acts corresponding to each claimed function in the means 
plus functions claimed in claims 8 and 1 5 according to 35 U.S.C. § 1 12, sixth paragraph. The 
means for carrying out the acts described in claims 8 and 15 include automated computing 
machinery and recording media for machine-readable information concisely described at pages 
1 1 - 12 in the original specification stating: 

The present invention is described primarily in terms of methods for 
administration of email and particularly in terms of methods for dynamically 
indicating client device status for client devices for displaying digital objects 
included in email. Persons skilled in the art, however, will recognize that any 
computer system that includes suitable programming means for operating in 
accordance with the disclosed methods also falls well within the scope of the 
present invention. 

Suitable programming means include any means for directing a computer system 
to execute the steps of the method of the invention, including for example, 
systems comprised of processing units and arithmetic-logic circuits coupled to 
computer memory, which systems have the capability of storing in computer 
memory, which computer memory includes electronic circuits configured to store 
data and program instructions, programmed steps of the method of the invention 
for execution by a processing imit. The invention also may be embodied in a 
computer program product, such as a diskette or other recording medium, for use 
with any suitable data processing system. 

Embodiments of a computer program product may be implemented by use of any 
recording medium for machine-readable information, including magnetic media, 
optical media, or other suitable media. Persons skilled in the art will immediately 
recognize that any computer system having suitable programming means will be 
capable of executing the steps of the method of the invention as embodied in a 
program product. Persons skilled in the art will recognize immediately that, 
although most of the exemplary embodiments described in this specification are 
oriented to software installed and executing on computer hardware, nevertheless, 
alternative embodiments implemented as firmware or as hardware are well within 
the scope of the present invention. 
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GROUNDS OF REJECTION 

In accordance with 37 CFR § 41.37(c)(l)(vi), Applicants provide the following concise 
statement for each grovind of rejection: 

1. Claims 1,4-8, 11-15, and 18-21 are rejected under 35 U.S.C § 103(a) as being anticipated 
by Shaffer, et al. (U.S. Patent No. 6,092,114). 

2. Claims 2, 3, 9, 10, 16, and 17 are rejected under 35 U.S.C § 103(a) as being anticipated 
by Shaffer, et al. (U.S. Patent No. 6,092,1 14) in view of Schwalm, et al. (U.S. Patent No. 
5,339,361). 

ARGUMENT 

Applicants present the following arguments pursuant to 37 CFR § 41.37(c)(l)(vii) regarding the 
two grounds of rejection in the present case. 

Argument Regarding The First Ground Of Rejection: 
Claims 1, 4-8, 11-15, and 18-21 Are Unpatentable 
Under 35 U.S.C § 103(a) Over Shaffer 

Claims 1, 4-8, 11-15, and 18-21 are rejected for obviousness under 35 U.S.C. § 103(a) as being 
unpatentable over Shaffer, et al. (U.S. Patent No. 6,092,114). To estabUsh a prima facie case of 
obviousness, three basic criteria must be met. Manual of Patent Examining Procedure §2142. 
The first element of a prima facie case of obviousness under 35 U.S.C. § 103 is that the proposed 
modification of Shaffer must teach or suggest all of Applicants' claim limitations. In re Royka, 
490 F.2d 981, 985, 180 USPQ 580, 583 (CCPA 1974). The second element of a prima facie case 
of obviousness under 35 U.S.C. § 103 is that there must be a suggestion or motivation to modify 
Shaffer. In re Vaeck, 947 F.2d 488, 493, 20 USPQ2d 1438, 1442 (Fed. Cir. 1991). The third 
element of a prima facie case of obviousness under 35 U.S.C. § 103 is that there must be a 
reasonable expectation of success in the proposed modification of Shaffer. In re Merck & Co., 
Inc., 800 F.2d 1091, 1097, 231 USPQ 375, 379 (Fed. Cir. 1986). As demonstrated below, the 
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modification of Shaffer does not establish a prima facie case of obviousness. The rejection of 
claims 1, 4-8, 11-15, and 18-21 should therefore be withdrawn and the case should be allowed. 
Applicants respectfully traverse each rejection individually and request reconsideration of claims 
1,4-8, 11-15, and 18-21. 

The Proposed Modification Of Shaffer 
Does Not Teach Or Suggest All Of The Claim 
Limitations Of Applications Claims 

To establish a prima facie case of obviousness, the proposed modification of Shaffer must teach 
or suggest all of the claim limitations of independent claims 1, 4-8, 11-15, and 18-21. In re 
Royka, 490 F.2d 981, 985, 180 USPQ 580, 583 (CCPA 1974). As Applicants will demonstrated 
below, Shaffer does not disclose each and every element of independent claim 1, and Shaffer 
therefore does not establish a prima facie case of obviousness v^dthin the meaning of 35 U.S.C. § 
103. 

Claim 1 of the present application claims: 

1 . A method of email administration comprising the steps of: 

receiving in a transcoding gateway from a client device one or more email 
display status attributes describing one or more email display capability 
statuses for a domain; 

receiving in the transcoding gateway from a sender an email display 
capabihty status request for the domain, wherein the capability status 
request comprises a domain identification; 

fmding, in dependence upon the domain identification, at least one email 
display capability status record for the domain, wherein the email display 
capability status record for the domain comprises at least one of the email 
display capability status attributes; and 
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sending at least one of the email display capability status attributes to the 
sender. 



Shaffer Neither Teaches Nor Suggests Receiving In A Transcoding 
Gateway From A Client Device One Or More Email Display Status Attributes 
Describing One Or More Email Display Capabilitv Statuses For A Domain 

The first element of claim 1 claims "receiving in a transcoding gateway from a client device one 
or more email display status attributes describing one or more email display capability statuses 
for a domain. ..." Regarding the first element of claim 1, the Final Office Action at page 2 states: 

receiving in a transcoding gateway from a client device one or more email display 
status attributes describing one or more email display capability statuses for a 
domain, (Col. 2, lines 30-65 & Col. 6, lines 31-53); 

That is, the Final Office Action takes the position that Shaffer at column 2, lines 30-65. and 
column 6, lines 3 1-53, teaches or suggests the first element of claim 1 . Applicants respectfully 
note in response, however, that what Shaffer at column 2, lines 30-65, in fact discloses is: 

A method and system for exchanging electronic messages, such as email 
messages, include out-tasking conversions of file formats when it is determined 
that a client device does not include the resources to directly access an attachment 
without conversion. The access requirements of each attachment to electronic 
messages are compared to the capabilities of the client device to which the 
attachment is to be transferred. If it is determined that a file-format conversion is 
required, the conversion operation is assigned to a server that supports the process 
of reformatting the attachment. In an email environment, the server may be 
substantially equivalent to the conventional email server, but includes enhanced 
conversion capabilities. 

In one embodiment, the determination of whether an attachment is accessible 
without conversion by a target client device occurs at the server. One means of 
enabling the server to execute the determination is to maintain a universal register 
of applications at the server. The universal register may be a lookup table that 
identifies each application program stored at each client device supported by the 
server. The lookup table may also include data that matches each user (i.e., 
potential recipient) with a client device at which the user typically accesses 
messages (e.g., a target computer). When a message is received at the server, the 
file format of any attachment is identified. In its simplest form, this is 
accomplished by looking at the file extension (e.g., .BMP identifies a bitmap 
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graphics fomat and MPEG indicates a specific video format). Alternatively, the 
format indicator may be embedded by the sending party within the message that 
includes the attachment. As a third possibility, the server may access each 
attachment in order to identify its file format. If a file-format conversion is 
necessary, the conversion can be implemented at the server, thereby freeing 
resources and processing time at the target client device. In this embodiment, the 
conversion may be transparent to the receiving party. 

That is, Shaffer at column 2, lines 30-65, discloses an email server capable of file-format 
conversion based on the applications installed on a client device. The Final Office Action 
attempts to equate Shaffer's email server capable of file-format conversion with the transcoding 
gateway claimed in the present application. The transcoding gateway claimed in the present 
application, however, receives one or more email display status attributes that describe one or 
more email display capability statuses for a domain. For further explanation. Applicants 
describe the 'email display status attributes' in the original specification in the paragraph 
begirming at line 18 of page 43 stating: 

In addition to display capability attributes, the example display capability status 
records (1730) also have display capability status attributes including availability 
(1904) and recent usage (1906). The availability field (1904) is a status indication 
whether a display capability is currently available to receive email or to display 
digital objects included in email. Availability of a capability is affected by, for 
example, whether a client device or display device is powered off or on, or 
whether a client device or display device is online or offline. The recent usage 
field (1906) is a status indication of a recent time when a capability was used, that 
is, for example, a recent date and time when a client device received email or 
when a display device played or displayed a transcoded digital object or file. 

That is, email display status attributes describe the status of an email display capability such as, 
for example, whether a display device is powered on or powered off Shaffer's email server 
capable of file-format conversion does not receive one or more email display status attribute 
describing one or more email display capability statuses for a domain as claimed in the present 
application. The only thing that Shaffer's email server receives is an email with an attachment 
and the applications installed in the client device — neither of which teach receiving one or more 
email display status attributes as claimed in the present application because the email and the 
applications installed in the client device are not email display status attributes. Regarding the 
other limitations of the first element of claim 1, Shaffer at column 2, lines 30-65, does not even 
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mention 'email display capability statuses for a domain,' 'transcoding gateway,' 'receiving in a 
transcoding gateway from a client device one or more email display status attributes describing 
one or more email display capability statuses for a domain.' Shaffer's email server capable of 
file-format conversion based on the applications installed on a client device, therefore, does not 
teach or suggest receiving in a transcoding gateway from a client device one or more email 
display status attributes describing one or more email display capability statuses for a domain as 
claimed in the present application. Because the proposed modification of Shaffer does not teach 
or suggest each and every element and limitation of Applicants' claims, the proposed 
modification of Shaffer does not establish a prima facie case of obviousness, and the rejections 
should be withdrawn. 



Turning now to Shaffer at column 6, lines 31-53, Applicants respectfully note in response that 
what Shaffer at column 6, lines 31-53, in fact discloses is: 

At step 44, the access capabilities of the target client device 14, 16 and 18 are 
determined. Referring to FIG. 1, an application register 34 may be maintained at 
the server level. As is well known in the art, computers typically maintain an 
application register of programs stored at the computer. The application register 
34 of FIG. 2 may be considered to be a universal application register that 
identifies all of the access capabilities of various client devices that are used to 
access email stored at the local server 12. In one embodiment, the application 
register is maintained as a lookup table. When a client device is first used to 
access email stored at the local server, the client device is polled to identify its 
access capabilities. The polling process may also be used to periodically update a 
lookup table that is compiled within memory of the server or within memory of an 
adjunct device. While the format converter 30 and the application register 34 are 
shown as being connected to the local ser\ er 12, the operations of the converter 
and register may be integrated into known servers. As an alternative to the polling 
approach, the client devices 14, 16 and 18 may be programmed to identify their 
individual access capabilities each time that a program is upgraded or added to the 
client device. 

That is, Shaffer at column 6, lines 3 1-53, discloses receiving access capabilities from a target 
device in a server. The Final Office Action attempts to equate Shaffer's access capabilities with 
the email display status attributes claimed in the present application. As explained above, the 
email display status attributes as claimed in the present application describe email display 
capability status such as, for example, whether a display device is powered on or powered off. 
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Shaffer's access capabilities merely describe whether a client device has an application installed 
on the client device to open a particular type of file. Shaffer's access capabilities, however, have 
nothing whatsoever to do with email display status attributes claimed in the present application. 
Regarding the other limitations of the first element of claim 1, Shaffer at column 6, lines 31-53, 
does not even mention 'email display capability statuses for a domain,' 'transcoding gateway,' 
'receiving in a transcoding gateway from a client device one or more email display status 
attributes describing one or more email display capability statuses for a domain.' Shaffer's 
receiving access capabilities from a target device in a server, therefore, does not teach or suggest 
receiving in a transcoding gateway from a client device one or more email display status 
attributes describing one or more email display capability statuses for a domain as claimed in the 
present application. Because the proposed modification of Shaffer does not teach or suggest 
each and every element and limitation of Applicants' claims, the proposed modification of 
Shaffer does not establish a prima facie case of obviousness, and the rejections should be 
withdrawn. 

Shaffer Neither Teaches Nor Suggests Receiving In The Transcoding 
Gateway From A Sender An Email Displav Capability Status Request For The 
Domain. Wherein The Capability Status Request Comprises A Domain Identification 

The second element of claim 1 claims 'receiving in the transcoding gateway from a sender an 
email display capability status request for the domain, wherein the capability status request 
comprises a domain identification. ...' Regarding the second element of claim 1, the Final Office 
Action at page 2 states: 

receiving in the transcoding gateway from a sender an email display capability 
status request for the domain, wherein the capability status request comprises a 
domain identification, (Col. 6, lin?s 6-67 & Co. 7, lines 1-38)... 

That is. Hie Final Office Action takes the position that Shaffer at column 6, lines 6-67, and 
column 7, lines 1-38, teaches or suggests the second element of claim 1 . Applicants respectfully 
note in response, however, that what Shaffer at column 6, lines 6-67, and column 7, lines 1-38, 
discloses in summary is receiving an email at an email server, checking the file format of an 
attachment, determining whether a client device is capable of accessing the attachment, 
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converting, locally or remotely as needed, the attachment to a format accessible by the client 
device, and notification of the sender if conversion is not possible. The Final Office Action 
attempts to equate Shaffer's email server that provides file-format conversion with the 
transcoding gateway as claimed in the present application. The transcoding gateway as claimed 
in the present application receives from a sender an email display capability status request for the 
domain. In contrast to the transcoding gateway of the present application, the only thing 
Shaffer's email server receives from a sender is an email with an attachment. Shaffer's email 
server never once receives an email display capability status request. Shaffer's failure to teach 
an email display capability status request, however, is understandable because Shaffer does not 
teach or suggest email display capability status as explained above. Furthermore, the email 
display capability status request as claimed in the present application is a status request for a 
domain. In contrast, Shaffer is clearly oriented to a single target/client device and not to the 
display capability status request for an entire domain as claimed in the present application. 
Regarding the other limitations of the second element of claim 1, Shaffer at column 6, lines 6-67, 
and column 7, lines 1-38, does not even mention 'wherein the capability status request comprises 
a domain identification,' 'email display capability status request for the domain,' or 'receiving in 
the transcoding gateway Irom a sender an email display capability status request for the domain, 
wherein the capability status request comprises a domain identification.' Shaffer at column 6, 
lines 6-67, and column 7, lines 1-38, therefore, does not teach or suggest receiving in the 
transcoding gateway from a sender an email display capability status request for the domain, 
wherein the capability status request comprises a domain identification. Because the proposed 
modification of Shaffer does not teach or suggest each and every element and limitation of 
Applicants' claims, the proposed modification of Shaffer does not establish a prima facie case of 
obviousness, and the rejections should be withdrawn. 

Despite the fact that Shaffer at column 6, lines 6-67, and column 7, lines 1-38, does not teach or 
suggest the second element of claim 1, the Final Office Action at pages 2 and 3 asserts that 
receiving in the transcoding gateway from a sender an email display capability status request for 
the domain as claimed in the present application is rendered obvious by Shaffer's email server 
that receives an email message stating: 
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Examiner notes that Shaffer discloses a message sent by a sender to the server 
where a determination is made based on client capabilities, wherein said message 
would obviously be a default means of requesting capability status, especially in 
light of the fact that Shaffer discloses a capability status determination, a 
conversion means, and a notification to sender means, all related to the ability of 
the client/target device to receive the sender's message, and wherein the sender is 
notified of a client's inability to receive the message based on conversion 
requirements, which requirements are obviously an indication of the 
client/domain ability/capability to receive the sender's message. 

That is, the Final Office Action sets forth a conclusory argument that the second element of 
claim 1 is disclosed because "said message would obviously be a default means of requesting 
capability status. ..." and incorrectly states that "Shaffer discloses a capability status 
determination." As explained above in detail, Shaffer does not disclose an email display 
capability status. In fact, Shaffer never once mentioned the status of anything. Shaffer, 
therefore, can disclose neither a "capability status determination" as quoted above nor an email 
display capability status request as claimed in the present application. Receiving in the 
transcoding gateway from a sender an email display capability status request for the domain as 
claimed in the present application, therefore, is not rendered obvious by Shaffer's email server 
that receives an email message. Because the proposed modification of Shaffer does not teach or 
suggest each and every element and limitation of Applicants' claims, the proposed modification 
of Shaffer does not establish a prima facie case of obviousness, and the rejections should be 
withdrawn. 



The Final Office Action at pages 2 and 3 also asserts that the second element of claim 1 is 
rendered obvious by Shaffer's email server that receives an email message stating: 



Additionally, the motivation to request client capability is also found within 
Shaffer which teaches the need for files to be accessible to the client device as 
well as a conversion consideration, wherein both conversion time and data loss 
are important access file/sharing issues, (Col. 1, lines 55-67 & Col. 2, lines 1- 
27)... 

That is, the Final Office Action argues that receiving in the transcoding gateway from a sender 
an email display capability status request for the domain as claimed in the present application is 
rendered obvious by Shaffer's email server that receives an email message in light of Shaffer at 
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column 1, lines 55-67, and column 2, lines 1-27. Applicants respectfully note in response, 
however, that what Shaffer at column 1, lines 55-67, and column 2, lines 1-27, in fact discloses 



Even if the attached file is properly decoded at the receiving client device, the file 
will not be accessible unless the client device has the required application 
program for opening the attached file. Typically, an attachment has a file format 
that is specific to an application. For example, an email attachment of a word 
processing text file may be specific to a particular word processing program. 
Access to the text is possible only if the receiving client device includes the 
program or has the capability of converting the decoded file to another file format 
that is accessible. Video, audio and graphics files typically have more exacting 
demands. For example, an AVI video formatted file is not converted to a MPEG 
video formatted file without significantly more complexity than the process of 
converting from one application-specific word processing file format to a second 
application-specific word processing file format. 

Many client devices have the capability of converting attachments from a limited 
number of inaccessible file formats to an acceptable me format. If the attachment 
is a relatively short word processing document, this capability is all that is 
required for efficient display of the document at the receiving client device. 
However, if the attached file is large, such as an intra-corporation multimedia 
presentation of a new product release, the required time to convert the attachment 
between file formats may lead to a significant inefficient use of the time of 
corporate personnel. Particularly in the conversion of multimedia file attachments, 
a complex algorithm must be utilized. 

Thus, if a file attachment is received that requires an application that is "foreign" 
to the receiving computing device, the first issue is whether the computing device 
is capable of converting the attachment to an accessible file format. A second 
issue relates to the time requirements of the conversion process, if a conversion is 
executable. A third issue relates to the reliability of the conversion operation. 
Often, the conversion causes data loss. 

What is needed is a messaging method and system that provide an efficient and 
reliable exchange of attached files m a multi-application environment. 

That is, Shaffer at column 1, lines 55-67, and column 2, lines 1-27, discloses that attachments are 
not accessible to a client device unless the client device has the required application program for 
opening the attached file and that client devices often have the capability of converting 
attachments from only a limited number of inaccessible file formats to an acceptable me format. 
Shaffer at column 1, lines 55-67, and column 2, lines 1-27, however, does not mention anything 
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related to an email display capability status or an email display capability status request as 
claimed in the present application. Shaffer's email server that receives an email message in light 
of Shaffer at column 1, lines 55-67, and column 2, lines 1-27, therefore, does not teach or 
suggest receiving in the transcoding gateway from a sender an email display capability status 
request for the domain as claimed in the present application as claimed in the present application. 
Because the proposed modification of Shaffer does not teach or suggest each and every element 
and limitation of Applicants' claims, the proposed modification of Shaffer does not establish a 
prima facie case of obviousness, and the rejections should be withdrawn. 

Shaffer Neither Teaches Nor Suggests Finding, In Dependence Upon 
The Domain Identification. At Least One Email Display Capability Status Record 
For The Domain, Wherein The Email Display Capability Status Record For The 
Domain Comprises At Least One Of The Email Display Capability Status Attributes 

The third element of claim 1 claims 'finding, in dependence upon the domain identification, at 
least one email display capability status record for the domain, wherein the email display 
capability status record for the domain comprises at least one of the email display capability 
status attributes. . . . ' Regarding the third element of claim 1 , the Final Office Action at pages 3 
and 4 states: 

finding, in dependence upon the domain identification, at least one email display 
capability status record for the domain, wherein the email display capability status 
record for the domain comprises at least one of the email display capability status 
attributes, (Col. 6, lines 6-67 & Col. 7, lines 1-38); 

That is, the Final Office Action takes the position that Shaffer at column 6, lines 6-67 and 
column 7, lines 1-38 discloses the third element of claun 1. Applicants respectfully note in 
response, however, that what Shaffer at column 6, lines 6-67, and column 7, lines 1-38, discloses 
in summary is receiving an email at an email server, checking the file format of an attachment, 
determining whether a client device is capable of accessing the attachment, converting, locally or 
remotely as needed, the attachment to a format accessible by the client device, and notification of 
the sender if conversion is not possible. The Final Office Action attempts to equate Shaffer's 
determining whether a client device is capable of accessing the attachment with finding, in 
dependence upon the domain identification, at least one email display capability status record for 
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the domain, wherein the email display capability status record for the domain comprises at least 
one of the email display capability status attributes as claimed in the present application. Finding 
an email display capability status record for a domain as claimed in the present application is 
concerned with identifying email display capability status for an entire destination domain. In 
contrast, Shaffer is clearly oriented to a single target/client device and not to the display 
capability status of a domain as claimed in the present application. Moreover, Shaffer's 
determination of whether a client device is capable of accessing an attachment discloses nothing 
whatsoever regarding email display capability status as claimed in the present application. 
Nothing in Shaffer ever detects or advises a sender of the status of the email display capability of 
a device such as, for example, whether the email display capability of the device is powered on 
or when a capability was recently used, or any other actual status information. Shaffer at column 
6, lines 6-67, and column 7, lines 1-38, therefore, cannot teach or suggest finding, in dependence 
upon the domain identification, at least one email display capability status record for the domain, 
wherein the email display capability status record for the domain comprises at least one of the 
email display capability status attributes as claimed in the present application. Because the 
proposed modification of Shaffer does not teach or suggest each and every element and 
limitation of Applicants' claims, the proposed modification of Shaffer does not establish a prima 
facie case of obviousness, and the rejections should be withdrawn. 

Shaffer Neither Teaches Nor Suggests Sending 
At Least One Of The Email Display Capability Status 
Attributes To The Sender Element Of The Independent Claims 

The fourth element of claim 1 claims "sending at least one of the email display capability status 
attributes to the sender." Regarding tlie fourth element of claim 1, the Final Office Action at 
page 4 states: 

sending at least one of the email display capability status attributes to the sender, 
(Col. 6, lines 6-67 & Col. 7, lines 1-38).... 

That is, the Final Office Action takes the position that Shaffer at column 6, lines 6-67, and 
column 7, lines 1-38, discloses the fourth element of claim 1. Applicants respectfully note in 
response, however, that what Shaffer at column 6, lines 6-67, and column 7, lines 1-38, discloses 
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in summary is receiving an email at an email server, checking the file format of an attachment, 
determining whether a client device is capable of accessing the attachment, converting, locally or 
remotely as needed, the attachment to a format accessible by the client device, and notification of 
the sender if conversion is not possible. The Final Office Action attempts to equate Shaffer's 
notification of the sender if conversion is not possible with sending at least one of the email 
display capability status attributes to the sender as claimed in the present application. Sending 
email display capability status attributes for a domain to a sender as claimed in the present 
apphcation is a process that informs a sender of the email display capability status for an entire 
destination domain during preparation of an email message, so that the sender can select a target 
device that is actually presently available and on-line, for example, and avoid the entire process 
of trial and error disclosed in Shaffer. Furthermore, Shaffer's notification of the sender when 
conversion is not possible is clearly oriented to a single target/client device and not to the display 
capability status of an entire domain as claimed here. In addition, Shaffer's notification of the 
sender when conversion is not possible discloses nothing whatsoever regarding email display 
capability status as claimed in the present application. Nothing in Shaffer ever detects or advises 
a sender of the status of the email display capability of a device such as, for example, whether 
the email display capability of the device is powered on or when a capability was recently used, 
or any other actual status information. Shaffer at column 6, lines 6-67, and column 7, lines 1-38, 
does not, therefore, teach or suggest sending at least one of the email display capability status 
attributes to the sender as claimed in the present application. Because the proposed modification 
of Shaffer does not teach or suggest each and every element and limitation of AppUcants' claims, 
the proposed modification of Shaffer does not establish a prima facie case of obviousness, and 
the rejections should be withdrawn. 



Relations Among Claims 



Independent claim 1 claims method aspects of email administration according to embodiments of 
the present invention. Independent claims 8 and 1 5 respectively claim system and computer 
program product aspects of email administration according to embodiments of the present 
invention. Claim 1 is allowable for the reasons set forth above. Claims 8 and 15 are allowable 
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because claim 1 is allowable. The rejections of claims 8 and 15 therefore should be withdrawn, 
and claims 8 and 15 should be allowed. 

Claims 4-7, 11-14, and 18-21 depend respectively from independent claims 1, 8, and 15. Each 
dependent claim includes all of the limitations of the independent claim from which it depends. 

Because the proposed modification of Shaffer does not teach or suggest each and every element 
of the independent claims, so also the proposed modification of Shaffer cannot possibly teach or 
suggest each and every element of any dependent claim. The rejections of claims 4-7, 11-14, and 
1 8-21 therefore should be withdrawn, and these claims also should be allowed. 

Argument Regarding The Second Ground Of Rejection: 

Claims 2, 3, 9, 10, 16, and 17 Are Unpatentable 
Under 35 U.S.C § 103(a) Over Shaffer In View of Schwalm 

Claims 2, 3, 9, 10, 16, and 17 stand rejected for obviousness under 35 U.S.C § 103(a) as being 
unpatentable over Shaffer (U.S. Patent 6,092,114) in view of Schwahn, etal, (U.S. Patent No. 
5,339,361). To establish a prima facie case of obviousness, three basic criteria must be met. 
Manual of Patent Examining Procedure §2142. The first element of a prima facie case of 
obviousness under 35 U.S.C. § 103 is that the proposed combination of Shaffer and Schwalm 
must teach or suggest all of Applicants' claim limitations. In re Royka, 490 F.2d 981, 985, 180 
USPQ 580, 583 (CCPA 1974). The second element of a prima facie case of obviousness under 
35 U.S.C. § 103 is that there must be a suggestion or motivation to combine Shaffer and 
Schwalm. In re Vaeck, 947 F.2d 488, 493, 20 USPQ2d 1438, 1442 (Fed. Cir. 1991). The third 
element of a prima facie case of obviousness under 35 U.S.C. § 103 is that there must be a 
reasonable expectation of success in the proposed combination of Shaffer and Schwalm. In re 
Merck & Co., Inc., 800 F.2d 1091, 1097, 231 USPQ 375, 379 (Fed. Cir. 1986). As demonstrated 
below, the proposed combination of Shaffer and Schwalm does not estabUsh a prima facie case 
of obviousness. The rejection of claims 2, 3, 9, 10, 16, and 17 should therefore be withdrawn 
and the case should be allowed. Applicants respectfully traverse each rejection individually and 
request reconsideration of claims 2, 3, 9, 10, 16, and 17. 
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The Proposed Combination Of Shaffer and Schwalm 
Does Not Teach Or Suggest All Of The Claim 
Limitation Of Applicants Claims 

To iestablish a prima facie case of obviousness, the proposed combination of Shaffer and 
Schwalm must teach or suggest all of the claim limitations of dependent claims 2, 3, 9, 10, 16, 
and 17. In re Royka, 490 F.2d 981, 985, 180 USPQ 580, 583 (CCPA 1974). The Final Office 
Action relies on the previous 35 U.S.C. § 103 rejection above to reject claims 2, 3, 9, 10, 16, and 
17. As Applicants have demonstrated above, the proposed modification of Shaffer does not 
teach or suggest each and every element of independent claims 1,8, and 15. Dependent claims 
2, 3, 9, 10, 16, and 17 depend from independent claims 1, 8, and 15 and include all of the 
limitations of the claims from which they depend. Because the proposed combination of Shaffer 
and Schwalm relies on the argument that the proposed modification of Schaffer discloses each 
and every element of claims 1, 8, and 1 5, and because the proposed modification of Shaffer in 
fact does not teach or suggest each and every element of claims 1,8, and 15, the proposed 
combination of Shaffer and Schwalm cannot teach or suggest all the claim limitations of claims 
2, 3, 9, 10, 16, and 17. The proposed combination of Shaffer and Schwalm, therefore, cannot 
establish a prima facie case of obviousness, and the rejections should be withdrawn. 



No Suggestion or Motivation to Combine Shaffer and Schwalm 



To establish a prima facie case of obviousness, there must be a suggestion or motivation to 
combine Shaffer and Schwalm. In re Vaeck, 947 F.2d at 493, 20 USPQ2d at 1442. The 
suggestion or motivation to combine Shaffer and Schwalm must come from the teaching of the 
references themselves, and the Examiner must explicitly point to the teaching within Shaffer or 
Schwalm suggesting the proposed combination. Absent such a showing, the Examiner has 
impermissibly used "hindsight" occasioned by Applicants' own teaching to reject the claims. In 
re Surko, 1 1 F.3d 887, 42 U.S.P.Q.2d 1476 (Fed. Cir. 1997); In re Vaeck, 947 F.2d 488m 20 
U.S.P.Q.2d 1438 (Fed. Cir. 1991); In re Gorman, 933 F.2d 982, 986, 18 U.S.P.Q.2d 1885, 1888 
(Fed. Cir. 1991); In re Bond, 910 F.2d 831, 15 U.S.P.Q.2d 1566 (Fed. Cir. 1990); In re 
Laskowski, 871 F,.2d 115, 117, 10U.S.P.Q.2d 1397, 1398 (Fed. Cir. 1989). 
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The Final Office Action makes no clear mention whatsoever of any place in either of the 
references or elsewhere that suggests or provides any motivation for the proposed combination 
of Shaffer or Schwalm. The closest the Final Office Action comes to discussing motivation to 
combine is two cryptic references to obviousness in paragraph 9 on page 7 stating: 

[I]t would have been obvious to incorporate a sender verification means into the Shaffer 
system for purposes of providing controlled access and transmission/receipt confirmation 
by authorized parties, (Schwalm - Col. 1, lines 14-52), within an email system which 
already requires user verification like that of Schaffer, and wherein it would have been 
obvious to augment the Shaffer controlled access means by implementing sender 
verification as well. 

Applicants take the position that the Final Office Action is asserting that Schwalm at column 1, 
lines 14-52, provide the motivation or suggestion to combine Shaffer and Schwahn. Applicant 
respectfully note in response, however, that what Schwalm at column 1, lines 14-52, in fact 
discloses is: 



Users of electronic information transfer are fi-equently unable to control access to 
their transmission systems, to verify the data they send is received, when it was 
received, and whether it was received by an authorized person. Likewise, a 
recipient of electronic information is frequently unable to verify that the data they 
receive was sent by an authorized person or control access to the data sent to 
them. An electronic data interchange is one example of electronic information 
transfer and includes, but is not limited to facsimile transmissions, money 
transfers, modem transfers, security exchanges, electronic mail (E-mail), and 
government "secured" systems. 

Systems heretofore known have allowed for transmission and receipt of electronic 
information, but provide no means of verifying time of receipt or the identity of 
the person sending or receiving the electronic information or controlling access to 
the systems. For example, with current facsimile technology the sender receives 
verification that a number of pages were transmitted to a given telephone number. 
The sender does not know who is physically receiving the facsimile at the other 
end. Likewise, the recipient of a facsimile does not know who the sender is, other 
than a sending telephone number and perhaps a "name" associated with the 
sending facsimile machine. Additionally, organizations utilizing facsimile 
systems for communication would like to control and limit access to their 
systems. The current extensive use of facsimile transmissions during contract 
negotiations or for sales orders, sometimes involving millions of dollars, gives 
rise for a need for a better system for controlling access to facsimile machines, for 
verifying who sent the facsimile, who received the facsimile, and providing a 
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time-stamp for transmission and receipt of the facsimile. 

Therefore, a longfelt need has arisen for a system and method which provides 
controlled access and confirmation of transmission and receipt of electronic 
information by authorized parties. 

That is, Schwalm at column 1, lines 14-52, discloses that users of electronic information transfer 
are frequently unable to control access to their transmission systems, to verify the data they send 
is received, when it was received, and whether it was received by an authorized person. 
Schwalm generally discloses authenticating transmission and receipt of electronic information. 
See Schwalm at Title. Shaffer generally discloses determining the location for performing file- 
format conversions of email attachments. See Shaffer at Title. Schwalm's disclosure at column 
1, lines 14-52, that users of electronic information transfer are frequently unable to control access 
to their transmission systems neither motivates nor suggests combining Schwalm's 
authenticating transmission and receipt of electronic information with Shaffer's determining the 
location for performing file-format conversions of email attachments. In fact, Schwalm at 
column ] , lines 14-52, has nothing whatsoever to do with combining Schwalm's authenticating 
transmission and receipt of electronic information with Shaffer's determining the location for 
performing file- format conversions of email attachments. Schwalm at column 1, lines 14-52, 
merely sets forth the background for the invention of Schwalm. Because the Office Action does 
not point to an explicit teaching in either Shaffer or Schwalm that suggests or motivates the 
combination of Shaffer and Schwalm, the Office Action does not estabhsh a prima facie case for 
obviousness, the rejections should be withdrawn, and the claims should be allowed. 

Conclusion of Applicants' Arguments 

Claims 1, 4-8, 11-15, and 18-21 stand rejected under 35 U.S.C § 103(a) as unpatentable over 
Shaffer and claims 2, 3, 9, 10, 16, and 17 stand rejected under 35 U.S.C § 103(a) as unpatentable 
over Shaifer in view of Schwalm. For the reasons explained above, the Final Office Action does 
not establish a prima facie case of obviousness against Applicant's claims over Schaffer alone or 
in combination with Schwalm within the meaning of 35 U.S.C § 103(a). Claims 1-21 are 
therefore patentable and should be allowed. Applicants respectfully traverse individually each 
rejection to claims 1-21 and request reconsideration of claims 1-21. 
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In view of the forgoing arguments, reversal on ali grounds of rejection is requested. 

The Commissioner is hereby authorized to charge or credit Deposit Account No. 09-0447 for any 
fees requked or overpaid. 



RespecffiiMv/^bniitted, 



By:_ 



H. Artbusht 
Reg. No. 46,022 
Biggers & Ohanian, LLP 
P.O. Box 1469 
Austin, Texas 78767-1469 
Tel. (5 12) 472-9881 
Fax (512) 472-9887 
ATTORNEY FOR APPELLANTS 
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APPENDIX OF CLAIMS 
ON APPEAL IN PATENT APPLICATION OF 
WILLIAM K. BODIN, ETAL., SERIAL NO. 10/047,018 

CLAIMS 

What is claimed is: 

1 . A method of email administration comprising the steps of: 

receiving in a transcoding gateway from a client device one or more email display status 
attributes describing one or more email display capability statuses for a domain; 

receiving in the transcoding gatew^ay from a sender an email display capability status 
request for the domain, wherein the capability status request comprises a domain 
identification; 

finding, in dependence upon the domain identification, at least one email display 
capability status record for the domain, wherein the email display capability status record 
for the domain comprises at least one of the email display capability status attributes; and 

sending at least one of the email display capability status attributes to the sender. 

2. The method of claim 1 wherein the email display capability status request includes a 
sender identification identifying the sender, and the method further comprises 
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determining, in dependence upon the sender identification, that the sender is authorized to 
send email to a connection address in the domain. 

3. The method of claim 2 wherein determining that the sender is authorized to send email to 
a connection address in the domain further comprises finding, in dependence upon the 
sender identification and in dependence upon the domain identification, at least one 
sender authorization record, wherein: 

the sender authorization record represents authorization for the sender to send 
email to a connection address in the domain; 

the sender authorization record comprises sender authorization attributes 
including a connection address in the domain; and 

finding at least one email display capability record for the domain further 

comprises finding, in dependence upon the domain identification and in 
dependence upon the connection address, at least one email display capability 
status record for the domain. 

4. The method of claim 1 further comprising the steps of: 

receiving an email in a transcoding gateway, the email comprising an email address and 
at least one digital object; 
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determining, in dependence upon display capability attributes and the email address, 
whether the digital object is to be transcoded in the transcoding gateway, wherein the 
determining results in a determination; 

forwarding the email, including the digital object, to the email address, if the 
determination is that the digital object is not to be transcoded in the transcoding gateway; 
and 

if the determination is that the digital object is to be transcoded in the transcoding 
gateway, carrying out the further steps of: 

transcoding the digital object into a transcoded digital object; and 

downloading the transcoded digital object to a destination client device. 

5 . The method of claim 4 wherein: 

transcoding the digital object further comprises transcoding the digital object into a 
digital file having a digital format and a file name; and 
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downloading the transcoded digital object fixrther comprises downloading the digital file 
to a destination client device at an internet address recorded in an internet address field of 
a client device record, the client device record having: 

recorded in a mailbox address field in the client device record, a mailbox address 
identical to the email address of the email message, and, 

recorded in a digital file format code field of the client device record, a digital file 
format code indicating that the client device represented by the client device 
record is capable of receiving the digital format of the digital file. 

The method of claim 4 wherein determining, in dependence upon display capability 
attributes and the email address, whether the digital object is to be transcoded in the 
transcoding gateway, fiirther comprises finding a capability record having a connection 
address equal to the email address. 

The method of claim 4 wherein forwarding the email further comprises forwarding the 
entire email, including the digital object, to an email client in another transcoding 
gateway in a client device. 

A system of email administration comprising: 
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means for receiving in a transcoding gateway from a client device one or more email 
display status attributes describing one or more email display capability statuses for a 
domain; 

means for receiving in the transcoding gateway from a sender an email display capability 
status request for the domain, wherein the capability status request comprises a domain 
identification; 

means for finding, in dependence upon the domain identification, at least one email 
display capability status record for the domain, wherein the email display capability 
status record for the domain comprises at least one of the email display capability status 
attributes; and 

means for sending at least one of the email display capability status attributes to the 
sender. 

9. The system of claim 8 wherein the email display capability status request includes a 
sender identification identifying the sender, and the system fiirther comprises means for 
determining, in dependence upon the sender identification, that the sender is authorized to 
send email to a connection address in the domain. 

10. The system of claim 9 wherein means for determining that the sender is authorized to 
send email to a connection address in the domain further comprises means for finding, in 
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dependence upon the sender identification and in dependence upon the domain 
identification, at least one sender authorization record, wherein: 

the sender authorization record represents authorization for the sender to send 
email to a connection address in the domain; 

the sender authorization record comprises sender authorization attributes 
including a connection address in the domain; and 

means for finding at least one email display capability record for the domain 

further comprises means for finding, in dependence upon the domain 
identification and in dependence upon the connection address, at least one email 
display capability status record for the domain. 

1 1 . The system of claim 8 further comprising: 

means for receiving an email in a transcoding gateway, the email comprising an email 
address and at least one digital object; 

means for detennining, in dependence upon display capability attributes and the email 
address, whether the digital object is to be transcoded in the transcoding gateway, 
wherein the determining results in a determination; 
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means for forwarding the email, including the digital object, to the email address, if the 
determination is that the digital object is not to be transcoded in the transcoding gateway; 
and 

if the determination is that the digital object is to be transcoded in the transcoding 
gateway, means for carrying out the further steps of: 

transcoding the digital object into a transcoded digital object; and 

downloading the transcoded digital object to a destination client device. 

The system of claim 1 1 wherein: 

means for transcoding the digital object further comprises means for transcoding the 
digital object into a digital file having a digital format and a file name; and 

means for downloading the transcoded digital object further comprises means for 
downloading the digital file to a destination client device at an internet address recorded 
in an internet address field of a client device record, the client device record having: 

recorded in a mailbox address field in the client device record, a mailbox address 
identical to the email address of the email message, and. 
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recorded in a digital file format code field of the client device record, a digital file 
format code indicating that the client device represented by the client device 
record is capable of receiving the digital format of the digital file. 

13. The system of claim 11 wherein means for determining, in dependence upon display 
capability attributes and the email address, whether the digital object is to be transcoded 
in the transcoding gateway, further comprises means for finding a capability record 
having a connection address equal to the email address. 

14. The system of claim 1 1 wherein means for forwarding the email further comprises means 
for forwarding the entire email, including the digital object, to an email client in another 
transcoding gateway in a client device. 

15. A computer program product of email administration comprising: 
a recording medium; 

means, recorded on the recording medium, for receiving in a transcoding gateway from a 
client device one or more email display status attributes describing one or more email 
display capability statuses for a domain; 
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means, recorded on the recording medium, for receiving in the transcoding gateway from 
a sender an email display capability status request for the domain, wherein the capability 
status request comprises a domain identification; 

means, recorded on the recording medium, for finding, in dependence upon the domain 
identification, at least one email display capability status record for the domain, wherein 
the email display capability status record for the domain comprises at least one of the 
email display capability status attributes; and 

means, recorded on the recording medium, for sending at least one of the email display 
capability status attributes to the sender. 

16. The computer program product of claim 15 wherein the email display capability status 
request includes a sender identification identifying the sender, and the computer program 
product further comprises means, recorded on the recording medium, for determining, in 
dependence upon the sender identification, that the sender is authorized to send email to a 
cormection address in the domain. 

17. The computer program product of claim 16 wherein means, recorded on the recording 
medium, for determining that the sender is authorized to send email to a connection 
address in the domain further comprises means, recorded on the recording medium, for 
finding, in dependence upon the sender identification and in dependence upon the domain 
identification, at least one sender authorization record, wherein: 
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the sender authorization record represents authorization for the sender to send 
email to a connection address in the domain; 

the sender authorization record comprises sender authorization attributes 
including a connection address in the domain; and 

means, recorded on the recording medium, for finding at least one email display 
capability record for the domain further comprises means, recorded on the 
recording medium, for finding, in dependence upon the domain identification and 
in dependence upon the connection address, at least one email display capability 
status record for the domain. 

The computer program product of claim 15 further comprising: 

means, recorded on the recording medium, for receiving an email in a transcoding 
gateway, the email comprising an email address and at least one digital object; 

means, recorded on the recording medium, for determining, in dependence upon display 
capability attributes and the email address, whether the digital object is to be transcoded 
in the transcoding gateway, wherein the determining results in a determination; 
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means, recorded on the recording medium, for forwarding the email, including the digital 
object, to the email address, if the determination is that the digital object is not to be 
transcoded in the transcoding gateway; and 

if the determination is that the digital object is to be transcoded in the transcoding 
gateway, means, recorded on the recording medium, for carrying out the further steps of: 

transcoding the digital object into a transcoded digital object; and 

downloading the transcoded digital object to a destination client device. 

The computer program product of claim 1 8 wherein: 

means, recorded on the recording medium, for transcoding the digital object further 
comprises means, recorded on the recording medium, for transcoding the digital object 
into a digital file having a digital format and a file name; and 

means, recorded on the recording mediimi, for downloading the transcoded digital object 
fiirther comprises means, recorded on the recording medium, for downloading the digital 
file to a destination client device at an internet address recorded in an internet address 
field of a client device record, the client device record having: 
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recorded in a mailbox address field in the client device record, a mailbox address 
identical to the email address of the email message, and, 

recorded in a digital file format code field of the client device record, a digital file 
format code indicating that the client device represented by the client device 
record is capable of receiving the digital format of the digital file. 

20. The computer program product of claim 18 wherein means, recorded on the recording 
medium, for determining, in dependence upon display capability attributes and the email 
address, whether the digital object is to be transcoded in the transcoding gateway, further 
comprises means, recorded on the recording medium, for finding a capability record 
having a connection address equal to the email address. 

21. The computer program product of claim 18 wherein means, recorded on the recording 
medium, for forwarding the email further comprises means, recorded on the recording 
medium, for forwarding the entire email, including the digital object, to an email client in 
another transcoding gateway in a client device. 
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APPENDIX OF EVIDENCE 
ON APPEAL IN PATENT APPLICATION OF 
WILLIAM K. BODIN, ETAL., SERIAL NO. 10/047,018 

This is an evidence appendix in accordance with 37 CFR § 41.37(c)(l)(ix). 

There is in this case no evidence submitted pursuant to 37 CFR §§ 1.130, 1.131, or 1.132, nor is 
there in this case any other evidence entered by the examiner and relied upon by the appellants. 
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RELATED PROCEEDINGS APPENDIX 



This is a related proceedings appendix in accordance with 37 CFR § 41 .37(c)(l)(x). 

There are no decisions rendered by a court or the Board in any proceeding identified pursuant to 
37CFR§41.37(c)(l)(ii). 
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